Embodiments of the inventive subject matter generally relate to the field of data processing, or, more specifically, scheduling threads in a multiprocessor computer.
A thread is a unit of software execution on a multiprocessing computer. On such a computer, software programs are executed in units of execution called ‘processes’ that include all the processor registers, code segment and offset registers, data segment and offset registers, stack segment and offset registers, flag registers, instruction pointer registers, program counters, and so on, needed for execution of software programs. For efficiency, ‘processes’ are often organized further as threads, where each thread of a process individually possesses all the attributes needed for execution except that a thread shares memory among all the other threads of a process, thereby reducing the overhead of operating system switches from thread to thread (‘context switches’).
A ready queue contains all the threads of the system that are in the ‘ready’ state, waiting in priority order for dispatching to a processor. Threads are placed in the ready queue when they are first created and from a wait queue upon returns from system calls. When dispatched to a processor, each thread is typically authorized to occupy the processor for no more than a maximum amount of time referred to as a time ‘slice,’ after which the thread is said to be ‘preempted’ for return to the ready queue until other threads have a chance to run on the processor. Threads also are also typically placed on the ready queue when they are preempted while running on a processor; that is, when a higher priority thread arrives in the ready queue or when a thread's time slice expires.
Threads that are in the ‘wait’ state are maintained a wait queue. Threads in the wait state are often waiting for input/output returns from peripheral devices such as user input devices, display devices, communications adapters, memory, and others as will occur to those of skill in the art. Threads running on a processor are moved to the wait queue and to the ‘wait’ state when they issue system calls. Such system calls are often requests for data input from or output to peripheral devices.
An interrupt is a mechanism by which a computer subsystem or module external to a processor may interrupt the otherwise normal flow of operations on the processor. In particular, in interrupt-drive input/output processing, interrupts are provided so that a thread sending or receiving data to or from a peripheral device need not block and wait. Instead, the thread issues a system call and suspends operation while waiting on the wait queue for its data. When the peripheral device has the data ready, the peripheral device triggers an interrupt by signaling the processor, usually by way of a system bus. The processor ‘catches’ the interrupt, saves the running thread's operating context, and then hands control over to an interrupt handler that ‘clears’ the interrupt by processing it. The interrupted thread's saved operating context is at least all information needed to resume thread processing at the point at which it was interrupted, that is, at least the processor status registers and the location of the next instruction to be executed in the interrupted thread, in addition to whatever other information is needed by the particular operating system.
Modern interrupt handlers are typically split into two parts, a first level interrupt handler (“FLIH”) and a second level interrupt handler (“SLIH”). The first level interrupt handler discovers the cause of the interrupt. The first-level interrupt handler typically does not however process the interrupt. The first level interrupt handler instead typically calls a second level interrupt handler to process the interrupt. The second level interrupt handler is often associated with the particular device which generated the interrupt. After being called by the first level interrupt handler, the second level interrupt handler sits in the ready queue until processor time becomes available to process the interrupt.
Second level interrupt handlers may be assigned a lower priority than a thread currently running on the processor and therefore, may not have an opportunity to run for a relatively long period of time. In such situations, the second level interrupt handler often waits in the ready queue for some time before gaining access to the CPU to process the interrupt. When processing generates many interrupts, the delay in processing those interrupts caused by the second level interrupt handler waiting in the ready queue diminishes efficiency.
Prior art solutions included binding interrupt processing exclusively to a single processor or to a subset of the processors on a system and refraining from assigning threads to processors reserved for interrupt processing. Such an approach is relatively static, however, leaving interrupt processing on a subset of processors and thread processing on a subset of processors even when other processors would otherwise be available to spread occasional large loads of thread processing or interrupt processing. There is an ongoing need therefore for improvement in scheduling threads in a multi-processor computer system.